MongoDB 문서 지향 데이터베이스

1. 서론: NoSQL과 문서 지향 데이터베이스의 패러다임

1.1 관계형 데이터베이스(RDBMS)의 한계와 NoSQL의 대두

수십 년간 데이터 관리의 표준으로 자리 잡아 온 관계형 데이터베이스 관리 시스템(RDBMS)은 트랜잭션의 원자성, 일관성, 고립성, 지속성(ACID)을 보장하며 데이터의 무결성과 정합성을 유지하는 데 탁월한 성능을 보여왔다.1 그러나 21세기에 들어서면서 인터넷 애플리케이션의 폭발적인 성장과 함께 데이터의 형태와 규모, 그리고 처리 속도에 대한 요구사항이 급격하게 변화하였다. 소셜 미디어, 사물 인터넷(IoT), 빅데이터 분석 등에서 생성되는 방대한 양의 비정형 데이터는 RDBMS의 엄격하고 정형화된 스키마 구조에 담기 어려웠다.3

또한, 빠른 시장 변화에 대응하기 위한 애자일(Agile) 개발 방법론의 확산은 RDBMS의 또 다른 한계를 드러냈다.3 RDBMS에서 스키마 변경은 데이터베이스 관리자(DBA)의 개입이 필요한 복잡하고 시간이 많이 소요되는 작업으로, 빠른 반복과 지속적인 배포를 추구하는 개발 환경에서 병목 현상을 유발했다.5 애플리케이션의 요구사항이 변경될 때마다 데이터베이스 스키마를 수정하고 데이터를 마이그레이션하는 과정은 개발 속도를 현저히 저하시켰다.

이러한 배경 속에서 ’NoSQL’이라는 새로운 패러다임이 등장했다. ’NoSQL’은 ‘Not Only SQL’ 또는 ’Non-relational’을 의미하며, 전통적인 테이블 기반의 관계형 구조를 탈피한 모든 데이터베이스 시스템을 포괄하는 용어이다.5 NoSQL은 단일 기술을 지칭하는 것이 아니라, 데이터 모델에 따라 문서(Document), 키-값(Key-Value), 컬럼 지향(Column-oriented), 그래프(Graph) 등 다양한 유형으로 나뉜다.5 이들은 공통적으로 유연한 데이터 모델, 수평적 확장성, 그리고 높은 가용성을 특징으로 하며, 현대적인 웹 애플리케이션의 요구사항을 충족시키기 위해 설계되었다.

1.2 MongoDB의 정의: 문서(Document) 기반 데이터 모델의 핵심 철학

MongoDB는 NoSQL 데이터베이스 진영에서 가장 널리 알려지고 사용되는 문서 지향 데이터베이스(Document-Oriented Database)이다.3 2007년에 설립된 이래로, MongoDB는 전 세계 개발자 커뮤니티로부터 폭넓은 지지를 받으며 빠르게 성장해왔다.3

MongoDB의 핵심 철학은 데이터를 ’문서(Document)’라는 단위로 저장하고 관리하는 데 있다. 이는 RDBMS가 데이터를 테이블의 행(Row)과 열(Column)로 구조화하는 것과 근본적인 차이를 보인다. MongoDB의 문서는 BSON(Binary JSON) 형식으로 저장되며, 이는 개발자에게 친숙한 JSON(JavaScript Object Notation)과 매우 유사한 키-값 쌍(key-value pairs)의 집합이다.3

이러한 문서 모델은 현대 프로그래밍 언어에서 사용하는 네이티브 객체(Native Object) 구조와 직접적으로 매핑된다.3 예를 들어, 사용자 정보를 담고 있는 자바스크립트 객체는 다음과 같을 수 있다.

{
"userId": "user123",
"name": "John Doe",
"email": "john.doe@example.com",
"interests": ["mongodb", "nodejs", "react"],
"address": {
"street": "123 Main St",
"city": "Anytown"
}
}

이 객체는 별도의 변환 과정 없이 거의 그대로 MongoDB 문서로 저장될 수 있다. 이는 개발자가 데이터를 데이터베이스 스키마에 맞추기 위해 정규화(Normalization)하거나, 객체와 관계형 테이블 간의 불일치를 해결하기 위한 복잡한 ORM(Object-Relational Mapping) 계층을 설계할 필요가 없음을 의미한다.3 애플리케이션의 데이터 구조를 자연스럽게 데이터베이스에 영속화할 수 있다는 점은 개발 생산성을 극적으로 향상시키는 MongoDB의 핵심적인 장점이다.

1.3 주요 특징 개괄: 유연성, 확장성, 그리고 개발자 중심 설계

MongoDB의 성공은 단순히 새로운 기술을 제시했기 때문이 아니라, 현대 소프트웨어 개발 패러다임의 변화와 깊이 연관되어 있다. 애자일과 DevOps 문화의 확산은 빠른 반복과 유연성을 핵심 가치로 삼았고, RDBMS의 경직된 스키마 관리 프로세스는 이러한 흐름에 장애물로 작용했다. MongoDB는 이러한 문제에 대한 명확한 해답을 제시하며, 다음과 같은 주요 특징을 통해 개발자 중심의 데이터베이스로 자리매김했다.

• 유연한 스키마 (Flexible Schema): MongoDB의 가장 큰 특징은 스키마를 강제하지 않는다는 점이다. 하나의 컬렉션(RDBMS의 테이블에 해당) 안에 있는 문서들이 서로 다른 필드와 구조를 가질 수 있다.3 이는 비즈니스 요구사항이 진화함에 따라 애플리케이션의 데이터 모델을 손쉽게 변경하고 확장할 수 있게 해준다. 개발자는 더 이상 스키마 변경을 위해 DBA의 승인을 기다리거나 복잡한 마이그레이션 작업을 수행할 필요 없이, 코드 변경과 함께 데이터 모델을 즉시 수정할 수 있다. 이러한 접근 방식은 “데이터가 코드처럼 된다(Data becomes like code)“는 개념으로 설명되며, 개발자에게 데이터 모델에 대한 완전한 주도권을 부여한다.3
• 수평적 확장성 (Horizontal Scalability): MongoDB는 설계 초기부터 대규모 확장을 염두에 두고 만들어졌다. 단일 서버의 성능을 높이는 수직적 확장(Vertical Scaling) 방식은 비용이 기하급수적으로 증가하고 물리적 한계에 부딪히기 쉽다.2 반면, MongoDB는 샤딩(Sharding)이라는 메커니즘을 통해 여러 서버에 데이터를 분산 저장함으로써 시스템 전체의 용량과 처리량을 늘리는 수평적 확장(Horizontal Scaling)을 기본적으로 지원한다.3 이는 저렴한 범용 하드웨어를 사용하여 거의 무한에 가까운 확장이 가능함을 의미한다.
• 풍부한 쿼리 언어 및 인덱싱: NoSQL 데이터베이스가 초기에 단순한 키-값 조회 기능만 제공했던 것과 달리, MongoDB는 매우 풍부하고 표현력 있는 쿼리 언어를 제공한다.10 필터링, 정렬, 집계 등 RDBMS에서 가능했던 대부분의 데이터 조회 및 조작이 가능하다. 또한, 문서 내의 어떤 필드, 심지어 내장된 문서나 배열의 요소에 대해서도 인덱스를 생성할 수 있어, 대용량 데이터에서도 빠른 검색 성능을 보장한다.7

이러한 특징들은 MongoDB가 단순히 기술적 대안을 넘어, 개발자의 경험(Developer Experience)을 최우선으로 고려하여 설계되었음을 보여준다. 프로그래밍 언어의 객체와 닮은 데이터 모델, 직관적인 쿼리, 그리고 주요 프로그래밍 언어에 대한 폭넓은 드라이버 지원 3 등은 모두 개발자의 인지적 부담을 줄이고 생산성을 극대화하는 데 초점을 맞추고 있다. 이는 데이터베이스가 더 이상 분리된 인프라의 일부가 아니라, 애플리케이션 코드의 자연스러운 확장이라는 현대적 관점을 반영하며, 데이터베이스 관리의 책임 일부가 개발팀으로 이동하는 조직적 변화까지도 유도하고 있다.

2. MongoDB 핵심 데이터 모델 분석

MongoDB의 아키텍처와 성능을 이해하기 위해서는 그 근간을 이루는 핵심 데이터 모델에 대한 깊이 있는 분석이 선행되어야 한다. 문서, 컬렉션, 그리고 이들을 효율적으로 처리하기 위한 BSON 형식은 MongoDB의 모든 특징을 관통하는 기본 요소이다.

2.1 문서(Documents)와 컬렉션(Collections)

MongoDB의 데이터 모델은 세 가지 기본 구성 요소, 즉 데이터베이스(Database), 컬렉션(Collection), 그리고 문서(Document)로 이루어진다.

• 문서(Document): MongoDB에서 데이터가 저장되는 기본 단위로, 하나의 레코드를 의미한다.12 문서는 필드(field)와 값(value)이 쌍을 이루는 구조로, BSON(Binary JSON) 형식으로 저장된다.8 이는 RDBMS의 행(Row)에 해당하지만, 훨씬 더 유연하고 풍부한 표현력을 가진다.13 문서는 문자열, 숫자, 날짜와 같은 기본 데이터 타입뿐만 아니라, 다른 문서를 값으로 내장(embed)하거나 값들의 배열(array)을 포함할 수 있다.3 이러한 중첩 구조 덕분에, RDBMS에서는 여러 테이블에 걸쳐 표현해야 할 복잡한 관계형 데이터를 단일 문서 내에 통합하여 표현하는 것이 가능하다. 이는 데이터 조회 시 값비싼 조인(join) 연산의 필요성을 크게 줄여주는 핵심적인 장점이다.
• 컬렉션(Collection): 문서들의 그룹으로, RDBMS의 테이블(Table)과 유사한 개념이다.1 하지만 결정적인 차이점은 컬렉션이 스키마를 강제하지 않는다는 것이다.12 즉, 하나의 컬렉션에 포함된 문서들은 서로 다른 필드와 구조를 가질 수 있다.6 예를 들어, users 컬렉션에는 어떤 사용자는 phone_number 필드를 가지고 있고, 다른 사용자는 해당 필드가 없을 수 있다. 이러한 유연성은 애플리케이션의 진화에 따라 데이터 모델을 쉽게 변경할 수 있게 해준다.
• _id 필드: MongoDB의 모든 문서는 _id라는 고유한 필드를 반드시 가져야 한다.9 이 필드는 컬렉션 내에서 각 문서를 유일하게 식별하는 기본 키(Primary Key) 역할을 한다. 만약 문서를 삽입할 때 사용자가 _id 값을 명시적으로 지정하지 않으면, MongoDB는 12바이트 크기의 ObjectId를 자동으로 생성하여 할당한다.7 ObjectId는 타임스탬프, 머신 ID, 프로세스 ID, 그리고 카운터 값을 조합하여 생성되므로, 분산 환경에서도 높은 확률로 고유성이 보장된다.

RDBMS에 익숙한 사용자를 위해, 두 시스템 간의 핵심 용어를 비교하면 다음과 같다.

2.2 BSON(Binary JSON)의 역할과 중요성

MongoDB는 데이터를 외부적으로는 JSON과 유사한 형태로 다루지만, 내부적으로 저장하고 전송할 때는 BSON이라는 형식을 사용한다.3 BSON은 “Binary JSON“의 약자로, JSON과 유사한 데이터 구조를 이진(binary) 형태로 직렬화한 포맷이다.16 BSON을 채택한 것은 MongoDB의 성능과 기능성에 지대한 영향을 미치는 핵심적인 설계 결정이다.

BSON의 기술적 장점은 다음과 같다.

• 확장된 데이터 타입 (Extended Data Types): JSON은 문자열, 숫자, 불리언, 배열, 객체, null이라는 제한된 데이터 타입만을 지원한다.17 이는 데이터베이스 시스템에서 요구되는 다양한 데이터 유형을 표현하기에 부족하다. 예를 들어, JSON에는 날짜(Date) 타입이 없어 문자열이나 숫자로 변환하여 저장해야 한다. BSON은 이러한 한계를 극복하기 위해 날짜(Date), 이진 데이터(Binary Data, 예: 이미지나 파일), 64비트 정수, 그리고 MongoDB 고유의 ObjectId 등 다양한 추가 데이터 타입을 지원한다.15 이는 데이터베이스 엔진이 날짜 기반 연산이나 이진 데이터 처리를 훨씬 더 효율적으로 수행할 수 있게 한다.
• 빠른 파싱과 탐색 (Fast Parsing and Traversability): 텍스트 기반인 JSON은 특정 필드의 값을 읽기 위해 문서의 처음부터 해당 필드를 만날 때까지 순차적으로 텍스트를 파싱해야 한다.19 문서가 크고 구조가 복잡할수록 이 과정은 비효율적이다. 반면, BSON은 각 필드 앞에 해당 필드의 타입과 길이를 명시하는 메타데이터를 포함한다.15 이 덕분에 데이터베이스 엔진은 전체 문서를 파싱하지 않고도 특정 필드를 찾기 위해 불필요한 부분을 빠르게 건너뛸(skip) 수 있다.19 이러한 ’탐색 가능성(traversability)’은 특히 내장된 문서(embedded documents)나 배열 내부의 특정 값에 접근할 때 쿼리 처리 속도를 극적으로 향상시킨다.

BSON의 선택은 단순히 기술적 선호의 문제가 아니라, 문서 모델의 잠재력을 최대한 발휘하기 위한 필연적인 결정이었다. MongoDB의 강력한 기능인 문서 임베딩(embedding)은 관련 데이터를 하나의 문서에 모아 조인의 필요성을 줄이는 데 있다.8 그러나 customer.address.zipcode와 같이 깊이 중첩된 필드를 효율적으로 쿼리하려면 빠른 탐색 기능이 필수적이다. 만약 MongoDB가 순수 JSON을 사용했다면, 이러한 중첩 필드에 접근하는 비용이 너무 커져 문서 모델의 실용성이 크게 저하되었을 것이다. 따라서, BSON의 빠른 탐색 기능은 문서 모델의 가장 강력한 특징인 임베딩을 성능적으로 뒷받침하는 기술적 기반이라고 할 수 있다.

물론 BSON에도 트레이드오프는 존재한다. 이진 형식이므로 사람이 직접 읽고 디버깅하기가 어렵고 16, 타입과 길이 정보라는 메타데이터 때문에 아주 작은 문서의 경우에는 텍스트 기반 JSON보다 오히려 크기가 더 커질 수도 있다.16 하지만 데이터베이스 엔진의 관점에서는 이러한 단점을 상쇄하고도 남을 만큼의 성능적 이점을 제공한다.

2.3 동적 스키마(Dynamic Schema)와 데이터 거버넌스

MongoDB의 컬렉션은 RDBMS의 테이블과 달리 사전에 정의된 고정된 스키마를 강제하지 않는다.6 이를 ‘동적 스키마’ 또는 ’유연한 스키마’라고 부른다. 이는 개발 과정에서 요구사항이 변경될 때마다 데이터베이스 스키마를 수정해야 하는 RDBMS의 번거로움을 해결하고, 빠른 프로토타이핑과 반복적 개발을 가능하게 하는 핵심적인 장점이다.3 또한, 형태가 일정하지 않은 다양한 데이터를 단일 컬렉션에 통합하여 저장하는 데 매우 유리하다.3

그러나 ’동적 스키마’라는 용어는 종종 ’스키마가 없음(No Schema)’으로 오해되기도 한다. 이는 정확한 표현이 아니다. 실용적인 애플리케이션이 작동하기 위해서는 데이터베이스가 스키마를 강제하지 않더라도, 애플리케이션 코드 수준에서는 암묵적인 스키마가 존재하고 관리되어야 한다. 이를 ‘애플리케이션 측 스키마(Application-Side Schema)’ 또는 ’읽기 시점의 스키마(Schema-on-Read)’라고 부르는 것이 더 정확하다.

완전한 유연성은 대규모 프로젝트나 여러 팀이 협업하는 환경에서 데이터의 일관성을 해치고 예측 불가능한 버그를 유발하는 원인이 될 수 있다.21 이러한 문제를 해결하기 위해 MongoDB는 스키마 유효성 검사(Schema Validation) 기능을 제공한다.5 이 기능을 사용하면 컬렉션에 문서가 삽입되거나 업데이트될 때, 특정 규칙을 준수하는지 검사하도록 설정할 수 있다. 예를 들어, 특정 필드가 반드시 존재해야 하는지, 필드의 데이터 타입이 무엇인지, 숫자 값의 범위가 어떠해야 하는지 등을 강제할 수 있다.

스키마 유효성 검사의 도입은 MongoDB가 단순한 유연성을 넘어 엔터프라이즈급 데이터 거버넌스 요구사항을 수용하며 성숙해왔음을 보여주는 중요한 지표이다. 이는 RDBMS의 엄격한 스키마와 NoSQL의 완전한 유연성 사이에서, 필요에 따라 스키마 강제 수준을 조절할 수 있는 실용적인 중간 지점을 제공한다. 개발 초기에는 유연성을 최대한 활용하여 빠르게 개발하고, 시스템이 안정화되고 데이터 구조가 확정되면 스키마 유효성 검사를 도입하여 데이터의 품질과 일관성을 보장하는 전략적 접근이 가능하다.

3. 고가용성 아키텍처: 레플리카 셋(Replica Sets)

현대 애플리케이션에서 데이터베이스의 중단은 곧 서비스의 중단을 의미한다. 따라서 데이터베이스 시스템은 하드웨어 장애, 네트워크 문제 등 예기치 않은 상황에서도 지속적으로 서비스를 제공할 수 있는 고가용성(High Availability)을 갖추어야 한다. MongoDB는 레플리카 셋(Replica Set) 이라는 아키텍처를 통해 이러한 요구사항을 충족시킨다. 운영 환경에서는 단일 장애점(Single Point of Failure)을 방지하기 위해 독립 실행형(standalone) 인스턴스가 아닌, 항상 레플리카 셋을 사용하는 것이 강력히 권장된다.22

3.1 Primary-Secondary 복제 메커니즘

레플리카 셋은 동일한 데이터 셋을 유지하는 둘 이상의 mongod 프로세스(노드) 그룹이다.23 이 그룹은 데이터의 여러 복사본을 서로 다른 서버에 저장함으로써 데이터 중복성(redundancy)과 고가용성을 동시에 달성한다. 레플리카 셋의 복제 메커니즘은 Primary-Secondary 모델을 기반으로 작동한다.

• Primary 노드: 레플리카 셋 내에서 오직 하나의 노드만이 Primary 역할을 수행한다. Primary 노드는 클라이언트로부터 오는 모든 쓰기(write) 연산(삽입, 수정, 삭제)을 처리하는 유일한 노드이다.23
• Secondary 노드: Primary 노드를 제외한 나머지 노드들은 모두 Secondary 역할을 한다. Secondary 노드들은 Primary 노드의 데이터를 지속적으로 복제하여 동일한 데이터 셋을 유지한다.26
• Oplog (Operations Log): 복제 과정의 핵심은 Oplog에 있다. Oplog는 Primary 노드에서 발생하는 모든 데이터 변경 연산을 순서대로 기록하는 특별한 Capped Collection(크기가 고정된 컬렉션)이다.27 Secondary 노드들은 이 Oplog를 비동기적으로(asynchronously) 가져와 자신의 데이터 셋에 순서대로 적용함으로써 Primary의 상태를 따라간다.26 Oplog의 각 연산은 멱등성(idempotent)을 가지도록 설계되어, 어떤 이유로든 동일한 연산이 Secondary에 여러 번 적용되더라도 최종 데이터 상태는 일관성을 유지한다.

3.2 자동 장애 조치(Automatic Failover)와 선거(Election)

레플리카 셋의 가장 중요한 기능 중 하나는 Primary 노드에 장애가 발생했을 때 자동으로 대처하는 능력이다. 이 과정은 Heartbeat와 선거(Election) 메커니즘을 통해 이루어진다.

• Heartbeat: 레플리카 셋의 멤버 노드들은 2초마다 서로에게 ’하트비트(heartbeat)’라는 신호를 보내 서로의 상태를 확인한다.25 만약 어떤 노드가 다른 노드로부터 10초 동안 하트비트 신호를 받지 못하면, 해당 노드를 접근 불가능한(unreachable) 상태로 간주한다.25
• 선거 프로세스: Secondary 노드들이 Primary 노드가 접근 불가능하다고 판단하면, 새로운 Primary를 선출하기 위한 선거 프로세스를 자동으로 시작한다.24 남은 Secondary 노드들은 서로 투표하여 새로운 Primary를 결정하는데, 이때 가장 최신 데이터를 가지고 있는(즉, 가장 최신 Oplog 항목을 가진) 노드가 Primary로 선출될 확률이 가장 높다. 선거에서 과반수의 표를 얻은 노드가 새로운 Primary로 승격되고, 이후 모든 쓰기 연산을 처리하기 시작한다. 이 모든 과정이 자동으로 이루어지기 때문에, 관리자의 개입 없이도 시스템은 수십 초 내에 정상 상태를 복구하고 다운타임을 최소화할 수 있다.23

3.3 레플리카 셋 구성 요소와 권장 구성

일반적인 레플리카 셋은 다음과 같은 세 가지 유형의 멤버로 구성될 수 있다.

• Primary (1개): 쓰기 연산을 담당한다.26
• Secondaries (1개 이상): 데이터를 복제하고, 읽기 연산을 분산 처리할 수 있다.26
• Arbiter (선택 사항, 0개 또는 1개): 데이터를 저장하지 않고 오직 선거 과정에서 투표권만 행사하는 특별한 유형의 노드다.26

선거 프로세스가 올바르게 작동하기 위해서는 분산 시스템의 근본적인 문제인 ’스플릿 브레인(split-brain)’을 방지해야 한다. 스플릿 브레인은 네트워크 단절로 인해 레플리카 셋이 두 개 이상의 그룹으로 나뉘었을 때, 각 그룹이 서로를 장애로 인식하고 독립적으로 새로운 Primary를 선출하려는 상황을 말한다. 이를 방지하기 위해 MongoDB 선거는 반드시 투표 가능한 멤버의 과반수(strict majority) 동의를 얻어야만 새로운 Primary를 선출할 수 있도록 설계되었다.

이러한 과반수 요구사항 때문에, 레플리카 셋의 투표 멤버 수는 홀수로 구성하는 것이 매우 중요하다. 만약 멤버가 짝수 개일 경우, 네트워크 단절로 인해 정확히 절반으로 나뉘면 어느 쪽도 과반수를 확보하지 못해 새로운 Primary를 선출하지 못하고 클러스터 전체가 쓰기 불능 상태에 빠질 수 있다.

이때 Arbiter가 유용하게 사용된다. Arbiter는 실제 데이터를 저장하지 않으므로 적은 리소스만으로 운영할 수 있으면서도, 투표권을 제공하여 전체 투표 멤버 수를 홀수로 맞추는 역할을 한다.23 예를 들어, Primary와 Secondary로만 구성된 2-노드 시스템은 장애 허용(fault tolerance)이 전혀 없지만, 여기에 Arbiter를 추가한 3-멤버(P-S-A) 구성은 노드 하나가 다운되어도 나머지 두 멤버가 과반수를 형성하여 정상 작동할 수 있다.

따라서, 운영 환경에서의 최소 권장 구성은 3개의 데이터 보유 멤버(Primary 1개, Secondary 2개)로 구성하는 것이다.26 이 구성은 멤버 하나가 장애로 다운되더라도 남은 두 멤버가 과반수(2/3)를 유지하여 새로운 Primary를 선출할 수 있으며, 데이터 역시 최소 두 곳에 복제되어 있어 안정성을 높일 수 있다.

3.4 읽기 설정(Read Preference)과 데이터 일관성

기본적으로 클라이언트의 모든 읽기 요청은 데이터의 최신 상태를 보장하기 위해 Primary 노드로 전달된다.26 하지만 MongoDB 드라이버는 읽기 설정(Read Preference) 옵션을 제공하여 클라이언트가 읽기 요청을 Secondary 노드로 보낼 수 있도록 허용한다.27

Secondary 노드에서 읽기를 수행하면 다음과 같은 이점이 있다.

• 읽기 확장성(Read Scalability): 읽기 부하를 여러 Secondary 노드로 분산시켜 Primary 노드의 부담을 줄이고, 전체 시스템의 읽기 처리량을 향상시킬 수 있다.23
• 데이터 지역성(Data Locality): 지리적으로 분산된 환경에서 사용자와 가까운 데이터 센터에 위치한 Secondary 노드에서 데이터를 읽게 함으로써 응답 시간을 단축할 수 있다.

그러나 이 방식에는 중요한 트레이드오프가 존재한다. Primary와 Secondary 간의 복제는 비동기적으로 이루어지기 때문에, Secondary 노드의 데이터는 Primary 노드에 비해 약간의 지연(replication lag)이 발생할 수 있다. 이는 ‘최종적 일관성(eventual consistency)’ 모델로, Secondary에서 읽은 데이터가 가장 최신의 데이터가 아닐 수 있음을 의미한다.

따라서 이 기능은 애플리케이션의 요구사항을 신중하게 고려하여 사용해야 한다. 예를 들어, 소셜 미디어의 타임라인이나 상품 추천 목록처럼 약간의 지연이 허용되는 데이터를 조회할 때는 Secondary 읽기를 활용하여 성능을 높일 수 있다. 반면, 금융 거래 처리나 결제 직전의 장바구니 총액 확인과 같이 데이터의 최신성과 강력한 일관성이 반드시 요구되는 작업은 반드시 Primary 노드에서 읽어야 한다. 이처럼 데이터베이스는 다양한 일관성 수준을 제공하는 메커니즘을 갖추고 있으며, 어떤 수준의 일관성을 요구할지는 애플리케이션 아키텍트가 전략적으로 결정해야 할 몫이다.

4. 수평적 확장 아키텍처: 샤딩(Sharding)

애플리케이션이 성장함에 따라 데이터의 양이 테라바이트, 페타바이트 단위로 증가하거나, 초당 수십만 건의 요청을 처리해야 하는 상황에 직면할 수 있다. 이러한 대규모 워크로드는 단일 서버의 물리적 한계를 쉽게 초과한다. MongoDB는 이러한 문제를 해결하기 위해 샤딩(Sharding) 이라는 수평적 확장(Horizontal Scaling) 아키텍처를 제공한다.28

4.1 샤딩의 원리: Scale-up vs. Scale-out

데이터베이스를 확장하는 방법은 크게 두 가지로 나뉜다.

• 수직적 확장 (Scale-up): 기존 서버의 하드웨어 사양(CPU, RAM, 스토리지 등)을 더 좋은 것으로 교체하여 성능을 높이는 방식이다.29 이 방식은 구현이 비교적 간단하지만, 고사양 하드웨어의 비용이 기하급수적으로 증가하며, 결국에는 더 이상 업그레이드할 수 없는 물리적 한계에 도달하게 된다.2
• 수평적 확장 (Scale-out): 더 많은 서버를 클러스터에 추가하여 데이터와 워크로드를 분산시키는 방식이다.30 MongoDB의 샤딩은 바로 이 수평적 확장을 구현하는 기술로, 저렴한 범용 서버들을 추가함으로써 이론적으로 거의 무한한 확장이 가능하다.31

샤딩은 하나의 거대한 데이터셋을 여러 개의 작은 조각(shard)으로 나누어 여러 서버에 분산 저장하는 원리다.30 이를 통해 단일 서버가 감당해야 했던 저장 용량과 처리 부하를 여러 서버가 나누어 가지게 되므로, 시스템 전체의 성능과 용량이 선형적으로 증가하게 된다.

4.2 샤드 클러스터의 구성 요소

MongoDB의 샤드 클러스터는 다음과 같은 세 가지 핵심 구성 요소로 이루어진다.28

• 샤드 (Shard): 분산된 데이터의 일부(subset)를 실제로 저장하는 서버 또는 서버 그룹이다. 각 샤드는 그 자체로 고가용성과 데이터 안정성을 보장하기 위해 반드시 레플리카 셋으로 구성되어야 한다.28 즉, 샤드 클러스터는 여러 개의 레플리카 셋이 모여 하나의 거대한 데이터베이스처럼 동작하는 구조다.

• mongos 라우터 (Query Router): 클라이언트 애플리케이션과 샤드 클러스터 사이의 게이트웨이 역할을 하는 프로세스다. 클라이언트는 개별 샤드에 직접 연결하는 것이 아니라, mongos 라우터에 연결하여 쿼리를 보낸다.29

mongos는 설정 서버로부터 메타데이터를 참조하여, 해당 쿼리를 처리해야 할 올바른 샤드(들)로 요청을 라우팅한다. 만약 쿼리가 여러 샤드에 걸쳐 있어야 한다면, mongos는 각 샤드로부터 결과를 수신하여 하나로 병합한 후 최종 결과를 클라이언트에게 반환하는 역할도 수행한다.28

• 설정 서버 (Config Servers): 샤드 클러스터의 ’두뇌’에 해당하는 매우 중요한 구성 요소다. 클러스터의 모든 메타데이터, 즉 어떤 데이터 조각(청크, chunk)이 어떤 샤드에 저장되어 있는지에 대한 매핑 정보를 저장하고 관리한다.28

mongos 라우터는 이 설정 서버의 정보를 바탕으로 쿼리를 라우팅한다. 설정 서버의 데이터가 유실되면 클러스터 전체가 동작 불능 상태에 빠질 수 있으므로, 설정 서버 자체도 반드시 고가용성을 위해 레플리카 셋으로 구성해야 한다.28

이러한 구성 요소들의 상호작용을 통해 샤드 클러스터의 장애 허용 범위가 계층적으로 결정된다. 개별 mongod 프로세스의 장애는 해당 샤드의 레플리카 셋이 처리한다. 하나의 샤드(레플리카 셋) 전체가 다운되더라도, 해당 샤드가 담당하던 데이터에 대한 접근만 불가능해질 뿐, 클러스터의 나머지 부분은 정상적으로 동작한다.28

mongos 라우터는 상태를 저장하지 않는(stateless) 프로세스이므로, 하나가 다운되면 클라이언트는 다른 mongos에 연결하면 된다.32 그러나 설정 서버 레플리카 셋의 장애는 mongos가 데이터의 위치를 알 수 없게 만들어 시스템 전체의 작동을 마비시키는 치명적인 장애로 이어진다. 따라서 운영 관점에서 가장 높은 우선순위와 모니터링 강도는 설정 서버에 집중되어야 한다.

4.3 샤드 키(Shard Key)의 중요성과 선택 전략

샤딩을 적용할 컬렉션을 결정했다면, 다음으로 가장 중요한 결정은 **샤드 키(Shard Key)**를 선택하는 것이다.28 샤드 키는 컬렉션의 문서를 여러 샤드에 어떻게 분산시킬지를 결정하는 기준이 되는 하나 이상의 필드다.31 샤드 키의 선택은 클러스터의 성능, 효율성, 그리고 확장성에 직접적이고 결정적인 영향을 미치므로 매우 신중하게 설계해야 한다.28

좋은 샤드 키가 갖추어야 할 핵심적인 두 가지 속성은 다음과 같다.

• 높은 카디널리티 (High Cardinality): 샤드 키가 가질 수 있는 고유한 값의 수가 많아야 한다. 예를 들어, ‘상태’ 필드가 ‘활성’, ‘비활성’, ‘대기’ 세 가지 값만 가진다면, 이 필드를 샤드 키로 사용할 경우 최대 3개의 샤드에만 데이터가 분산될 수 있다.30 반면,

user_id나 email과 같이 고유한 값이 매우 많은 필드는 더 많은 샤드로 데이터를 분산시킬 수 있는 잠재력을 가진다.

• 균등한 분산 빈도 (Evenly Distributed Frequency): 데이터와 워크로드가 모든 샤드에 고르게 분산되어야 한다. 만약 특정 샤드 키 값에 데이터 접근이 집중된다면, 해당 데이터를 저장하는 샤드에만 부하가 몰리는 핫스팟(Hotspot) 현상이 발생한다.23 핫스팟은 클러스터의 다른 샤드들이 유휴 상태임에도 불구하고 특정 샤드의 병목 현상으로 인해 전체 시스템의 성능을 저하시키는 주된 원인이 된다.

잘못 선택된 샤드 키는 최상의 하드웨어와 인프라를 갖춘 클러스터조차도 심각한 성능 병목에 빠뜨릴 수 있다. MongoDB 5.0부터는 기존 컬렉션의 샤드 키를 변경하는 리샤딩(resharding) 기능이 도입되었지만, 이는 여전히 복잡하고 리소스를 많이 소모하는 작업이다.28 따라서 최초의 샤드 키 선택이 무엇보다 중요하다.

4.4 데이터 분산 전략

MongoDB는 샤드 키를 기반으로 데이터를 분산시키기 위해 주로 두 가지 전략을 사용한다.

• 범위 기반 샤딩 (Ranged Sharding): 샤드 키의 값 범위를 기준으로 데이터를 청크(chunk)라는 작은 단위로 나눈 뒤, 각 청크를 특정 샤드에 할당하는 방식이다.30 예를 들어, 주문 날짜를 샤드 키로 사용한다면, 1월 데이터는 샤드 A, 2월 데이터는 샤드 B에 저장하는 식이다. 이 방식은 2024년 1월 15일부터 1월 31일까지의 모든 주문과 같은 범위 기반 쿼리를 수행할 때 매우 효율적이다. mongos는 해당 데이터가 어떤 샤드(들)에 있는지 정확히 알고 있으므로, 불필요한 샤드에는 쿼리를 보내지 않는다. 하지만 순차적으로 증가하는 값(예: 타임스탬프, ObjectId)을 샤드 키로 사용하면, 모든 새로운 쓰기(write) 작업이 항상 마지막 범위를 담당하는 단일 샤드에 집중되는 심각한 쓰기 핫스팟을 유발할 수 있다.
• 해시 샤딩 (Hashed Sharding): 샤드 키 필드의 값을 해시 함수(hash function)에 통과시킨 후, 그 결과 해시 값을 기준으로 데이터를 분산하는 방식이다.30 해시 함수의 특성상, 샤드 키 값이 순차적으로 증가하더라도 해시 값은 전체 범위에 걸쳐 무작위로 분포하게 된다. 이 방식은 쓰기 작업을 클러스터 전체에 매우 균등하게 분산시키는 데 탁월한 장점이 있어 쓰기 핫스팟 문제를 효과적으로 해결할 수 있다. 그러나 범위 기반 쿼리를 처리할 때는 단점이 된다. 특정 값 범위를 조회하더라도, 해당 데이터가 어떤 샤드에 있는지 예측할 수 없으므로 mongos는 모든 샤드에 쿼리를 보내야만 한다(broadcast operation).

샤딩은 엄청난 확장성을 제공하는 강력한 기능이지만, 그 이면에는 상당한 운영 복잡성이 따른다. 샤드 키 선택은 애플리케이션의 데이터 접근 패턴에 대한 깊은 이해를 요구하는, 되돌리기 어려운 중대한 결정이다. 따라서 샤딩은 수직적 확장이 더 이상 경제적이거나 기술적으로 불가능할 때 고려해야 할 최종적인 확장 전략이며, 모든 애플리케이션의 기본 출발점으로 삼아서는 안 된다. 이는 단순한 기술적 선택을 넘어, 운영 및 비즈니스 차원의 전략적 결정이다.

5. 데이터 조작 및 쿼리: CRUD와 인덱싱

데이터베이스의 핵심 기능은 데이터를 효율적으로 저장하고, 필요할 때 정확하게 찾아내며, 수정하고 삭제하는 것이다. MongoDB는 이러한 기본 작업을 위해 직관적이면서도 강력한 CRUD(Create, Read, Update, Delete) 연산과, 대용량 데이터에서 빠른 검색을 보장하는 정교한 인덱싱 시스템을 제공한다.

5.1 기본 CRUD 연산

CRUD는 데이터베이스와 상호작용하는 네 가지 기본 연산을 의미하며, MongoDB는 각 연산에 대해 명확하고 일관된 메소드를 제공한다.34

• Create (생성): 컬렉션에 새로운 문서를 추가하는 연산이다.

• db.collection.insertOne(document): 단일 문서를 컬렉션에 삽입한다. 성공 시, 삽입된 문서의 _id를 포함하는 객체를 반환한다.34

db.users.insertOne({ name: "Alice", age: 30, status: "active" })

• db.collection.insertMany([doc1, doc2,...]): 문서들의 배열을 인자로 받아, 여러 문서를 한 번의 네트워크 요청으로 삽입한다. 대량의 데이터를 삽입할 때 insertOne을 반복 호출하는 것보다 훨씬 효율적이다.34

db.users.insertMany()

• Read (읽기): 컬렉션에서 문서를 조회하는 연산이다.

• db.collection.find(query, projection): 쿼리 조건(query)과 일치하는 모든 문서를 찾아내는 커서(cursor)를 반환한다.7 커서는 결과를 한 번에 모두 메모리에 올리지 않고, 필요에 따라 데이터를 가져오는 효율적인 방식이다. 쿼리 조건이 비어있으면({}) 컬렉션의 모든 문서를 반환한다.

// status가 "active"인 모든 사용자를 조회
db.users.find({ status: "active" })

• db.collection.findOne(query, projection): 쿼리 조건과 일치하는 첫 번째 문서를 반환한다. 일치하는 문서가 없으면 null을 반환한다.34

// 이름이 "Alice"인 사용자 한 명을 조회
db.users.findOne({ name: "Alice" })

• Update (수정): 기존 문서를 수정하는 연산이다.

• db.collection.updateOne(filter, update, options): 필터(filter) 조건과 일치하는 첫 번째 문서를 수정한다.34 수정할 내용을 정의하는 update 문서에는 $set, $inc와 같은 업데이트 연산자를 사용해야 한다.

// 이름이 "Alice"인 사용자의 나이를 31로 변경
db.users.updateOne({ name: "Alice" }, { $set: { age: 31 } })

• db.collection.updateMany(filter, update, options): 필터 조건과 일치하는 모든 문서를 수정한다.34

// status가 "inactive"인 모든 사용자의 status를 "pending"으로 변경
db.users.updateMany({ status: "inactive" }, { $set: { status: "pending" } })

• Delete (삭제): 문서를 컬렉션에서 제거하는 연산이다.

• db.collection.deleteOne(filter, options): 필터(filter) 조건과 일치하는 첫 번째 문서를 삭제한다.34

// 이름이 "Bob"인 사용자를 삭제
db.users.deleteOne({ name: "Bob" })

• db.collection.deleteMany(filter, options): 필터 조건과 일치하는 모든 문서를 삭제한다.34

// status가 "pending"인 모든 사용자를 삭제
db.users.deleteMany({ status: "pending" })

5.2 인덱스의 원리와 성능 영향

대규모 컬렉션에서 특정 문서를 찾기 위해 모든 문서를 처음부터 끝까지 순차적으로 확인하는 작업(컬렉션 스캔, Collection Scan)은 매우 비효율적이다.11 인덱스는 이러한 문제를 해결하기 위해 책의 목차와 같이 데이터의 특정 필드 값을 정렬된 상태로 유지하는 특별한 데이터 구조다.7

• 원리: 쿼리가 실행될 때, MongoDB 쿼리 옵티마이저는 해당 쿼리를 효율적으로 처리할 수 있는 인덱스가 있는지 확인한다. 적절한 인덱스가 존재하면, 전체 컬렉션을 스캔하는 대신 정렬된 인덱스를 먼저 탐색하여 원하는 문서의 위치를 빠르게 찾아낸다. 이를 통해 스캔해야 할 문서의 수를 극적으로 줄여 쿼리 성능을 비약적으로 향상시킨다.37
• 성능 영향: 인덱스는 데이터베이스 시스템의 근본적인 트레이드오프를 보여준다.
• 읽기 성능 향상: 인덱스의 주된 목적으로, find, sort, aggregate 등 읽기 관련 작업의 속도를 크게 개선한다.11
• 쓰기 성능 저하: 인덱스는 공짜가 아니다. 컬렉션에 문서가 삽입, 수정, 삭제될 때마다, 해당 컬렉션에 생성된 모든 인덱스 역시 새로운 데이터를 반영하기 위해 업데이트되어야 한다. 이 과정은 쓰기 작업에 추가적인 오버헤드를 발생시킨다.11 따라서 인덱스가 많을수록 쓰기 성능은 저하된다.

5.3 인덱스 유형별 심층 분석

MongoDB는 다양한 데이터 유형과 쿼리 패턴을 지원하기 위해 여러 종류의 인덱스를 제공한다.

• 단일 필드 인덱스 (Single Field Index): 가장 기본적인 인덱스 유형으로, 문서의 단일 필드에 대해 생성된다. _id 필드에는 기본적으로 고유한 단일 필드 인덱스가 생성된다.11

• 복합 인덱스 (Compound Index): 두 개 이상의 필드를 조합하여 하나의 인덱스를 생성한다. 복합 인덱스에서는 필드의 순서가 매우 중요하다.37 예를 들어, { "userid": 1, "score": -1 } 인덱스는 먼저 userid를 오름차순(1)으로 정렬하고, 동일한 userid 내에서는 score를 내림차순(-1)으로 정렬한다. 이 인덱스는 userid에 대한 쿼리, 또는 userid와 score를 함께 사용하는 쿼리에 효과적이지만, score만으로 쿼리할 때는 효율적으로 사용될 수 없다.

• 멀티키 인덱스 (Multikey Index): 필드의 값이 배열(array)일 경우, MongoDB는 해당 필드에 인덱스를 생성할 때 자동으로 멀티키 인덱스를 만든다.37 이 인덱스는 배열의 각 요소에 대해 개별적인 인덱스 엔트리를 생성하므로, 배열 내의 특정 값을 포함하는 문서를 효율적으로 찾을 수 있다.

• 특수 인덱스:

• 텍스트 인덱스 (Text Index): 문자열 필드의 내용에 대해 전문 검색(full-text search)을 지원하기 위한 인덱스다.11

• 지리 공간 인덱스 (Geospatial Index): 좌표 데이터를 저장하고, 특정 지점으로부터의 거리나 특정 영역 내 포함 여부 등을 쿼리하는 위치 기반 검색을 효율적으로 처리한다.11

• TTL 인덱스 (Time-To-Live Index): 특정 날짜 필드를 기준으로, 설정된 시간이 지나면 문서를 자동으로 삭제하는 특별한 인덱스다. 유효 기간이 있는 세션 정보, 로그 데이터, 캐시 데이터 등을 관리하는 데 매우 유용하다.37

• 부분 인덱스 (Partial Index): 컬렉션의 모든 문서가 아닌, 특정 필터 조건을 만족하는 문서의 서브셋에 대해서만 인덱스를 생성한다.37 이는 MongoDB의 유연한 스키마 모델에서 특히 강력한 도구다. 예를 들어,

orders 컬렉션에서 status가 “shipped“인 문서에 대해서만 shipping_date 필드에 인덱스를 생성할 수 있다. 이렇게 하면 인덱스의 크기가 줄어들고, “shipped” 상태가 아닌 문서가 변경될 때는 인덱스 업데이트 오버헤드가 발생하지 않아 쓰기 성능 저하를 최소화할 수 있다.

5.4 인덱싱 전략: ESR 규칙과 최적화

효과적인 인덱싱은 애플리케이션의 성능을 좌우하는 핵심 요소다. 따라서 인덱스는 무분별하게 생성하는 것이 아니라, 애플리케이션의 쿼리 패턴을 면밀히 분석하여 전략적으로 설계해야 한다.

• ESR (Equality, Sort, Range) 규칙: 복합 인덱스를 설계할 때 널리 사용되는 효과적인 가이드라인이다. 쿼리에서 사용되는 조건들을 세 가지 유형으로 나누고, 그 순서에 따라 인덱스 필드를 구성하는 것이다.37

1. Equality (동등 비교): 정확한 값 일치를 요구하는 조건(예: status: "A")에 사용되는 필드를 인덱스의 가장 앞에 둔다.

2. Sort (정렬): 결과를 정렬하는 데 사용되는 필드(예: sort({ timestamp: -1 }))를 그 다음에 둔다.

3. Range (범위 검색): 값의 범위를 검색하는 조건(예: age: { $gt: 18 })에 사용되는 필드를 가장 마지막에 둔다.

이 규칙을 따르면 인덱스가 다양한 쿼리를 효율적으로 커버할 수 있다.

• 인덱스 과다 생성의 부작용: 앞서 언급했듯이, 모든 인덱스는 쓰기 성능에 부담을 준다. 사용되지 않는 인덱스나 중복되는 인덱스는 불필요한 리소스 낭비이므로, 정기적으로 인덱스 사용 통계를 분석하여 최적화해야 한다.11

• 인덱스 선택성 (Selectivity): 인덱스의 효율성은 해당 필드가 얼마나 많은 고유한 값을 갖느냐에 따라 달라진다. user_id처럼 거의 모든 값이 고유한 필드는 선택성이 매우 높아 인덱스 효율이 극대화된다. 반면, ’성별’처럼 ‘남성’, ‘여성’ 등 몇 가지 값만 갖는 필드는 선택성이 낮아 인덱스를 통해 걸러낼 수 있는 데이터의 양이 적으므로, 인덱싱의 효과가 떨어진다.11

결론적으로, MongoDB의 성능 튜닝은 애플리케이션의 쿼리 패턴에 대한 깊고 사전적인 이해를 바탕으로 이루어져야 한다. 인덱싱은 개발 후반에 추가하는 부가적인 작업이 아니라, 데이터 모델링 및 애플리케이션 설계 단계부터 핵심적으로 고려되어야 할 필수적인 과정이다. explain() 명령을 통해 쿼리 실행 계획을 분석하고, 인덱스가 효과적으로 사용되고 있는지 지속적으로 모니터링하는 문화가 정착되어야 한다.

6. 고급 데이터 처리: 애그리게이션 프레임워크(Aggregation Framework)

단순한 데이터 조회(CRUD)를 넘어, 데이터를 그룹화하고, 통계를 계산하며, 복잡한 변환을 수행해야 할 필요가 있다. MongoDB는 이러한 요구사항을 데이터베이스 서버 내에서 효율적으로 처리하기 위해 강력한 **애그리게이션 프레임워크(Aggregation Framework)**를 제공한다. 이는 데이터를 애플리케이션으로 모두 가져와 메모리에서 처리하는 방식에 비해 네트워크 부하와 애플리케이션의 리소스 사용량을 크게 줄여준다.

6.1 파이프라인 개념: 데이터 처리의 흐름

MongoDB 애그리게이션의 핵심은 파이프라인(Pipeline) 개념에 있다.38 애그리게이션 파이프라인은 여러 개의 단계(Stage) 들이 순차적으로 연결된 데이터 처리 흐름이다.

컬렉션의 문서들은 파이프라인의 첫 번째 단계로 입력된다. 각 단계는 입력된 문서들에 대해 특정 연산(예: 필터링, 그룹화, 변환)을 수행하고, 그 결과를 다음 단계의 입력으로 전달한다.38 이러한 방식으로 데이터는 여러 단계를 거치면서 점진적으로 원하는 형태로 가공되고 요약된다.

예를 들어, “모든 주문 중에서 ‘전자제품’ 카테고리에 해당하는 주문들만 필터링하고($match), 월별로 그룹화하여($group) 총 판매액을 계산한 뒤, 판매액이 높은 순으로 정렬($sort)한다“와 같은 복잡한 분석 작업을 하나의 파이프라인으로 정의할 수 있다.

애그리게이션 프레임워크의 등장은 MongoDB가 단순한 문서 저장소를 넘어, 정교한 데이터 처리 플랫폼으로 진화했음을 보여준다. 초기의 NoSQL 시스템들이 복잡한 데이터 처리 로직을 애플리케이션 계층으로 미루었던 것과 달리, 애그리게이션 파이프라인은 풍부하고 선언적인 서버 측 데이터 처리 언어를 제공함으로써 이러한 경향을 역전시켰다.

6.2 주요 파이프라인 스테이지 상세 분석

애그리게이션 파이프라인은 다양한 기능을 수행하는 여러 스테이지들로 구성된다. 가장 핵심적이고 빈번하게 사용되는 스테이지는 다음과 같다.

• $match: 파이프라인으로 들어오는 문서들을 필터링하는 역할을 한다. SQL의 WHERE 절과 매우 유사하며, 표준 MongoDB 쿼리 문법을 사용한다.38

$match 스테이지는 처리할 문서의 수를 초기에 대폭 줄여 파이프라인 전체의 성능을 향상시키므로, 가능한 한 파이프라인의 가장 앞단에 배치하는 것이 성능 최적화의 핵심 원칙이다.42

• $group: 특정 필드를 기준으로 문서를 그룹화하고, 각 그룹에 대해 집계 연산을 수행한다. SQL의 GROUP BY 절에 해당한다.38

_id 필드에 그룹화할 기준 필드를 지정하고, 다른 필드에는 집계 연산자(accumulator)를 사용하여 그룹별 계산을 수행한다.

• $sum: 숫자 값의 합계를 계산한다.

• $avg: 숫자 값의 평균을 계산한다.

• $min/$max: 그룹 내 최소/최대값을 찾는다.

• $push: 그룹에 속한 문서들의 특정 필드 값을 배열로 만든다.

• $first/$last: 정렬된 그룹 내에서 첫 번째/마지막 문서의 값을 가져온다.

• $project: 출력될 문서의 구조를 재구성(reshape)하는 역할을 한다. SQL의 SELECT 절과 기능적으로 유사하다.39 이 스테이지를 통해 다음과 같은 작업을 수행할 수 있다.

• 특정 필드만 포함시키기 (값으로 1 또는 true 지정).

• 특정 필드를 제외하기 (값으로 0 또는 false 지정). 기본적으로 포함되는 _id 필드를 제외하려면 명시적으로 { _id: 0 }을 지정해야 한다.44

• 다양한 표현식(expression)을 사용하여 기존 필드의 값을 변환하거나 새로운 필드를 계산하여 추가할 수 있다.

• $sort: SQL의 ORDER BY 절처럼, 특정 필드를 기준으로 문서 스트림을 정렬한다.45 필드 이름에

1을 지정하면 오름차순, -1을 지정하면 내림차순으로 정렬된다.46

• $limit & $skip: $limit은 지정된 수만큼의 문서만 다음 단계로 전달하고, $skip은 지정된 수의 문서를 건너뛴다.43 이 두 스테이지를 조합하면, 웹 애플리케이션에서 흔히 사용되는 페이지네이션(Pagination) 기능을 효율적으로 구현할 수 있다.47

• $unwind: 배열 필드를 포함하는 문서를 입력받아, 해당 배열의 각 요소에 대해 문서를 하나씩 복제하여 출력한다. 즉, 하나의 문서를 배열의 크기만큼 여러 개의 문서로 “풀어헤치는” 역할을 한다.48 이는 배열 내의 각 항목을 개별적으로 분석하거나 그룹화해야 할 때 매우 유용하다.

• $lookup: 다른 컬렉션의 데이터와 조인(join) 연산을 수행한다. RDBMS의 왼쪽 외부 조인(left outer join)과 유사한 기능을 제공한다.41

localField(현재 컬렉션의 필드)와 foreignField(조인할 컬렉션의 필드)를 기준으로 두 컬렉션을 연결하고, 일치하는 문서들을 배열 형태로 새로운 필드에 추가한다.

6.3 실용적 애그리게이션 파이프라인 예제

애그리게이션 파이프라인의 강력함은 여러 스테이지를 조합하여 복잡한 분석을 수행할 때 드러난다. 다음은 온라인 상점의 orders 컬렉션과 products 컬렉션을 사용하여, 특정 기간 동안 가장 많이 팔린 상위 5개 상품의 이름과 총 판매 수량을 계산하는 파이프라인 예제이다.

시나리오: 2024년 1분기 동안 판매된 상품 중, 총 판매 수량 기준 상위 5개 상품의 이름과 수량을 조회한다.

• orders 컬렉션 구조 예시:

{
"_id": ObjectId("..."),
"orderDate": ISODate("2024-01-15T10:00:00Z"),
"items": [
{ "productId": "P101", "quantity": 2, "price": 50 },
{ "productId": "P203", "quantity": 1, "price": 120 }
]
}

• products 컬렉션 구조 예시:

{
"_id": "P101",
"name": "MongoDB T-shirt",
"category": "Apparel"
}

애그리게이션 파이프라인:

db.orders.aggregate( },
totalSold: "$totalQuantity"
}
}
])

이 파이프라인은 전통적인 분석 시스템에서 요구되던 복잡한 ETL(Extract, Transform, Load) 과정을 대체할 수 있는 강력한 가능성을 보여준다. MongoDB는 운영 데이터에 대해 직접적으로 이와 같은 복잡한 집계 연산을 수행할 수 있어, 실시간 대시보드, 개인화 추천 엔진, 사기 탐지 시스템 등 실시간 애플리케이션 중심 분석(real-time, application-driven analytics) 이라는 강력한 아키텍처 패턴을 가능하게 한다.50 이는 운영 시스템(OLTP)과 분석 시스템(OLAP) 사이의 경계를 허물고, 데이터가 생성되는 바로 그곳에서 즉각적인 통찰력을 얻을 수 있게 해주는 현대 데이터 아키텍처의 중요한 흐름을 반영한다.

7. MongoDB 생태계와 활용 사례

MongoDB의 성공은 뛰어난 데이터베이스 엔진뿐만 아니라, 개발과 운영을 지원하는 강력한 생태계 덕분이기도 하다. 완전 관리형 클라우드 서비스부터 직관적인 GUI 도구, 강력한 커맨드라인 인터페이스에 이르기까지, MongoDB는 개발자와 운영자가 데이터베이스를 효율적으로 활용할 수 있도록 다각적인 지원을 제공한다.

7.1 핵심 도구

MongoDB 생태계의 중심에는 개발, 관리, 운영의 전 과정을 지원하는 세 가지 핵심 도구가 있다.

• MongoDB Atlas: MongoDB사가 직접 개발하고 운영하는 완전 관리형 클라우드 데이터베이스 서비스(DBaaS)이다.51 사용자는 Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) 등 주요 클라우드 제공업체 위에서 단 몇 번의 클릭만으로 MongoDB 클러스터를 배포하고 운영할 수 있다. Atlas는 서버 프로비저닝, 클러스터 구성, 백업 및 복원, 소프트웨어 패치, 스케일링, 보안 설정, 모니터링 등 복잡하고 시간이 많이 소요되는 인프라 관리 작업을 모두 자동화해준다.21 이를 통해 개발팀과 운영팀은 인프라 관리에 대한 부담을 덜고, 핵심 비즈니스 로직과 애플리케이션 개발에 더 많은 시간을 집중할 수 있다. Atlas는 단순한 데이터베이스 호스팅을 넘어, 전문 검색을 위한 Atlas Search, AI 애플리케이션을 위한 Vector Search, 실시간 데이터 처리를 위한 Stream Processing 등 다양한 부가 서비스를 통합된 플랫폼 형태로 제공한다.51 이러한 전략은 Atlas를 단순한 DBaaS가 아닌, 포괄적인 ’데이터 플랫폼’으로 자리매김하게 하고 있다.

• MongoDB Compass: MongoDB를 위한 공식 GUI(Graphical User Interface) 도구로, 데이터베이스와의 상호작용을 시각적이고 직관적으로 만들어준다.53 Compass를 사용하면 다음과 같은 다양한 작업을 손쉽게 수행할 수 있다.

• 데이터 탐색: 컬렉션 내의 문서를 트리, 테이블, JSON 뷰 등 다양한 형식으로 시각적으로 탐색하고 필터링할 수 있다.53

• 스키마 분석: 컬렉션의 데이터를 샘플링하여 필드의 분포, 데이터 타입, 값의 범위 등을 시각화해주어 데이터 구조를 쉽게 파악할 수 있다.

• 쿼리 및 인덱스 관리: 쿼리를 직접 작성하고 실행하며, 쿼리 성능을 분석하는 ’Explain Plan’을 시각적으로 확인할 수 있다. 이를 바탕으로 필요한 인덱스를 생성하거나 비효율적인 인덱스를 제거하여 성능을 최적화할 수 있다.53

• 애그리게이션 파이프라인 빌더: 복잡한 애그리게이션 파이프라인을 각 단계별로 시각적으로 구축하고, 각 단계의 입력과 출력을 실시간으로 확인하며 디버깅할 수 있다.53

• mongosh (MongoDB Shell): MongoDB 서버와 상호작용하기 위한 현대적인 커맨드라인 인터페이스(CLI)이다.55 기존의

mongo 셸을 대체하는 mongosh는 구문 강조, 지능형 자동 완성, 명령 히스토리, 오류 메시지 개선 등 개발자 생산성을 높이는 다양한 기능을 제공한다. Node.js REPL 환경을 기반으로 하므로, 강력한 JavaScript 스크립팅을 통해 데이터베이스 관리 작업을 자동화하거나 복잡한 데이터 조작을 수행하는 데 매우 유용하다.

이러한 도구들의 발전, 특히 MongoDB Atlas에 대한 집중적인 투자는 데이터베이스 산업의 패러다임이 온프레미스 소프트웨어 판매에서 클라우드 기반 서비스형(as-a-service) 소비 모델로 전환되고 있음을 명확히 보여준다. Atlas는 진입 장벽을 낮추고, 운영 복잡성을 제거하며, 다양한 기능을 통합 제공함으로써 고객 가치를 극대화하고 클라우드 제공업체들의 네이티브 데이터베이스 서비스와 직접 경쟁하는 MongoDB의 핵심 전략이다.

7.2 주요 활용 분야 분석

MongoDB의 유연한 데이터 모델과 수평적 확장성은 다양한 산업 분야와 애플리케이션 유형에서 그 가치를 입증하고 있다.

• 빅데이터 및 실시간 분석: MongoDB의 수평적으로 확장 가능한 샤딩 아키텍처와 고성능 쿼리 및 애그리게이션 기능은 대용량 데이터를 저장하고 실시간으로 분석하는 데 이상적인 환경을 제공한다.4 특히 스키마가 고정되어 있지 않거나 자주 변경되는 로그 데이터, 클릭스트림 데이터, 소셜 미디어 피드, IoT 센서 데이터 등을 처리하는 데 탁월한 성능을 보인다.4 기존의 분석 시스템처럼 데이터를 별도의 데이터 웨어하우스로 옮기는 배치(batch) 과정 없이, 운영 데이터에 대해 직접 실시간 분석을 수행할 수 있다는 점이 큰 장점이다.58
• 콘텐츠 관리 시스템 (CMS): 블로그 포스트, 기사, 비디오, 이미지, 댓글 등 다양한 형태와 구조를 가진 콘텐츠를 관리해야 하는 CMS는 MongoDB의 유연한 문서 모델을 통해 큰 이점을 얻는다.20 각 콘텐츠 유형마다 다른 속성(메타데이터)을 가질 수 있는데, 이를 별도의 테이블이나 복잡한 EAV(Entity-Attribute-Value) 모델 없이 단일 컬렉션 내에서 직관적으로 표현하고 관리할 수 있다.4
• 전자상거래 플랫폼: 전자상거래 사이트는 상품 카탈로그, 사용자 프로필, 주문 내역, 재고, 세션 정보 등 매우 다양한 종류의 데이터를 다룬다. 특히 상품 카탈로그는 상품 유형에 따라 속성이 천차만별(예: 의류의 사이즈/색상, 전자기기의 스펙)인데, MongoDB의 문서 모델은 이러한 가변적인 속성을 가진 상품 정보를 효과적으로 저장할 수 있게 해준다.4
• 사물 인터넷 (IoT): 수백만, 수십억 개의 커넥티드 디바이스로부터 끊임없이 쏟아지는 대규모 시계열 데이터를 수집, 저장, 처리하는 데 MongoDB가 널리 사용된다. 각 센서나 디바이스마다 보내는 데이터의 형식이 다를 수 있으며, 데이터의 양이 폭발적으로 증가하기 때문에 유연한 스키마와 수평적 확장성이 필수적이다. 독일의 거대 기술 기업인 Bosch는 여러 사업부에서 발생하는 IoT 센서 데이터의 저장 및 분석을 위해 MongoDB를 성공적으로 활용하고 있다.4

이처럼 다양한 활용 사례, 특히 금융(MetLife 58, Barclays 4)이나 정부(인도의 디지털 신분증 시스템 Aadhaar 58)와 같이 보수적인 산업의 핵심 시스템에 MongoDB가 채택되고 있다는 사실은, 이 기술이 더 이상 스타트업의 전유물이 아닌, 성숙하고 신뢰할 수 있는 엔터프라이즈급 데이터 플랫폼으로 인정받고 있음을 시사한다. 이는 ACID 트랜잭션 지원, 강력한 보안 기능, 포괄적인 관리형 서비스(Atlas) 등 엔터프라이즈 환경에서 요구되는 핵심 기능들을 지속적으로 추가하며 발전해 온 결과이다.

8. 종합 평가: MongoDB의 장단점과 전략적 고려사항

MongoDB는 현대 애플리케이션 개발에 있어 강력하고 매력적인 선택지이지만, 모든 문제에 대한 만병통치약은 아니다. 기술을 성공적으로 도입하기 위해서는 그 장점을 극대화하고 단점을 명확히 인지하며, 해결하고자 하는 문제의 특성에 맞는지를 전략적으로 판단해야 한다.

8.1 장점 (Pros)

• 개발 생산성과 유연성: JSON과 유사한 문서 모델은 현대 프로그래밍 언어의 객체 구조와 자연스럽게 매핑되어 개발자가 직관적으로 데이터를 다룰 수 있게 한다.3 유연한 스키마는 비즈니스 요구사항의 변화에 따라 데이터 모델을 신속하게 수정하고 진화시킬 수 있게 하여, 애자일 개발 환경에서 비약적인 생산성 향상을 가져온다.6
• 뛰어난 확장성: 샤딩을 통한 수평적 확장(scale-out) 아키텍처는 MongoDB의 핵심적인 강점이다.56 데이터의 양이나 트래픽이 증가할 때, 고가의 단일 서버로 업그레이드하는 대신 저렴한 범용 서버를 클러스터에 추가하는 방식으로 거의 무한에 가깝게 시스템을 확장할 수 있다.10
• 고성능: 적절한 인덱싱 전략과 데이터 모델링(특히 임베딩을 통한 조인 회피)이 결합될 때, MongoDB는 매우 높은 읽기 및 쓰기 성능을 제공한다.10 특히 대량의 데이터를 한 번에 삽입하거나 업데이트하는 작업에서 RDBMS 대비 뛰어난 성능을 보인다.6
• 다양한 데이터 처리: 정형, 반정형, 비정형 데이터를 모두 단일 시스템 내에서 효과적으로 저장하고 쿼리할 수 있는 능력은 MongoDB를 다목적 데이터베이스로 만들어준다.4 이는 다양한 데이터 소스를 통합해야 하는 현대 애플리케이션에 큰 이점을 제공한다.

8.2 단점 (Cons)

• 복잡한 JOIN의 한계: MongoDB는 $lookup 애그리게이션 스테이지를 통해 다른 컬렉션과의 조인과 유사한 기능을 제공하지만, 이는 RDBMS의 고도로 최적화된 JOIN 연산에 비해 기능적으로나 성능적으로 제한적이다.10 복잡하고 다층적인 JOIN이 비즈니스 로직의 핵심을 이루는 애플리케이션에는 적합하지 않을 수 있다. 따라서 MongoDB를 효과적으로 사용하기 위해서는 데이터 모델링 단계에서부터 비정규화(denormalization)와 임베딩(embedding)을 통해 JOIN의 필요성을 최소화하는 설계가 권장된다.
• 높은 메모리 사용량: BSON 형식은 각 문서마다 필드 이름을 문자열 형태로 함께 저장한다. 이로 인해 문서의 수가 매우 많을 경우, RDBMS가 스키마 정보를 한 번만 저장하는 것에 비해 더 많은 디스크 공간과 메모리를 소비할 수 있다.10
• 다중 문서 트랜잭션의 복잡성: MongoDB는 이제 여러 문서나 컬렉션에 걸친 다중 문서 ACID 트랜잭션을 지원하지만 3, 이는 RDBMS에서처럼 데이터베이스 설계의 기본 전제가 아니다. 단일 문서 내에서의 연산은 원자적으로 보장되므로, 가급적 관련 데이터를 하나의 문서에 묶어 트랜잭션의 필요성 자체를 줄이는 데이터 모델링이 권장된다. RDBMS처럼 트랜잭션을 빈번하게 사용하는 패턴은 MongoDB의 성능에 부정적인 영향을 줄 수 있다.
• 데이터 중복과 일관성 관리: 성능 최적화를 위해 비정규화를 적극적으로 활용하는 MongoDB의 설계 철학은 필연적으로 데이터 중복을 야기한다. 예를 들어, 게시글 문서에 작성자의 이름을 함께 저장하는 경우, 작성자가 이름을 변경하면 해당 작성자가 쓴 모든 게시글 문서를 찾아 업데이트해야 한다. 이러한 데이터 일관성을 유지하기 위한 책임은 애플리케이션 계층으로 전가될 수 있다.10

널리 알려진 이러한 ’단점’들은 MongoDB가 진화하면서 상당 부분 완화되거나 새로운 관점에서 이해될 필요가 있다. 예를 들어, 트랜잭션과 조인 기능이 ’없는 것’이 아니라, 데이터베이스의 핵심 아키텍처가 그것들을 ‘피하도록’ 최적화되어 있다는 점이 중요하다. MongoDB를 RDBMS처럼 사용하려는 시도(빈번한 $lookup 사용, 잦은 다중 문서 트랜잭션)는 가능은 하지만, 종종 차선의 성능을 낳는다. MongoDB의 잠재력을 최대한 활용하기 위해서는 ’문서 지향적 사고(think in documents)’를 통해 그 고유의 데이터 모델링 패턴을 받아들이고, 트랜잭션이나 조인은 예외적인 경우에 사용하는 도구로 인식하는 것이 전략적으로 올바르다.

8.3 RDBMS와의 비교를 통한 선택 가이드

MongoDB와 RDBMS 사이의 선택은 더 이상 ’SQL 대 NoSQL’이라는 이분법적 대결이 아니다. 두 시스템 모두 각자의 영역에서 발전하며 서로의 장점을 일부 흡수하고 있다. RDBMS는 JSON 데이터 타입을 지원하며 유연성을 높이고 있고, MongoDB는 스키마 유효성 검사나 ACID 트랜잭션과 같은 관계형 데이터베이스의 특징을 도입했다. 따라서 선택의 기준은 기술의 우열이 아닌, 해결하고자 하는 문제의 본질과 애플리케이션의 특성에 맞춰져야 한다.

• MongoDB가 적합한 경우:
• 빠른 개발 주기와 불확실한 요구사항: 시장 출시 시간(Time-to-Market)이 중요하고, 초기 요구사항이 불명확하며 향후 많은 변화가 예상되는 프로젝트에 이상적이다.3
• 비정형/반정형 데이터 중심: 데이터의 구조가 다양하거나 예측 불가능할 때, 예를 들어 사용자 생성 콘텐츠, 로그 데이터, IoT 센서 스트림 등을 다룰 때 강력한 힘을 발휘한다.4
• 대규모 확장성 요구: 수평적 확장이 필수적인 대용량 데이터 및 높은 트래픽을 처리해야 하는 서비스에 적합하다.3
• 계층적 데이터 모델: 데이터 간의 관계가 주로 1:N 또는 포함(containment) 관계로, 중첩된 문서 구조로 자연스럽게 표현될 수 있을 때 최상의 성능을 보인다.
• RDBMS가 더 적합한 경우:
• 안정적이고 정형화된 데이터: 데이터 모델이 잘 정의되어 있고, 향후 변경 가능성이 낮으며, 엄격한 데이터 무결성과 정합성이 최우선 순위일 때(예: 전통적인 금융 거래, ERP 시스템) 신뢰할 수 있는 선택이다.2
• 복잡한 관계와 JOIN 중심: 데이터 간의 M:N 관계가 복잡하게 얽혀 있고, 여러 테이블에 걸친 복잡한 JOIN과 트랜잭션이 비즈니스 로직의 핵심을 이룰 때 RDBMS의 성능과 표현력이 빛을 발한다.21
• 데이터 중복 최소화: 데이터 정규화를 통해 데이터 중복을 최소화하고, 저장 공간의 효율성을 극대화하며, 데이터 일관성을 데이터베이스 차원에서 강력하게 보장받고 싶을 때 적합하다.2

궁극적으로, 아키텍트가 내려야 할 결정은 애플리케이션의 핵심 데이터 접근 패턴과 예상되는 진화 방향에 달려 있다. 애플리케이션의 핵심 가치가 안정적이고 고도로 관계적인 엔티티 모델에 있다면 RDBMS가 더 안전하고 성숙한 선택일 것이다. 반면, 애플리케이션의 경쟁력이 빠른 변화에 대한 대응 능력, 다양한 데이터 형태의 처리, 그리고 대규모 트래픽을 감당하는 수평적 확장 능력에 있다면, MongoDB의 문서 중심적이고 분산 시스템을 우선하는 아키텍처가 근본적인 이점을 제공할 것이다. 이는 유연성과 확장성을 우선할 것인가, 아니면 구조와 일관성을 우선할 것인가에 대한 전략적 선택이다.

9. 참고 자료

1. Difference between RDBMS and MongoDB - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/difference-between-rdbms-and-mongodb/
2. Relational Vs. Non-Relational Databases - MongoDB, https://www.mongodb.com/resources/compare/relational-vs-non-relational-databases
3. Why Use MongoDB And When To Use It?, https://www.mongodb.com/resources/products/fundamentals/why-use-mongodb
4. The Top 10 Real-World MongoDB Use Cases You Should Know in 2024, https://www.cdata.com/blog/mongodb-use-cases
5. Types Of Databases | MongoDB, https://www.mongodb.com/resources/basics/databases/types
6. Comparing The Differences - MongoDB Vs MySQL, https://www.mongodb.com/resources/compare/mongodb-mysql
7. MongoDB: An introduction - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/mongodb-an-introduction/
8. Introduction to MongoDB - Database Manual, https://www.mongodb.com/docs/manual/introduction/
9. MongoDB – Document Based NoSQL database - Webskitters Academy, https://www.webskittersacademy.in/mongodb-document-based-nosql-database/
10. Understanding the Pros and Cons of MongoDB - KnowledgeNile, https://www.knowledgenile.com/blogs/pros-and-cons-of-mongodb
11. Performance Considerations in MongoDB Indexes - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/performance-considerations-in-mongodb-indexes/
12. FAQ: MongoDB Fundamentals - Database Manual, https://www.mongodb.com/docs/manual/faq/fundamentals/
13. Rows vs Documents vs Sub-documents - Working with Data - MongoDB, https://www.mongodb.com/community/forums/t/rows-vs-documents-vs-sub-documents/224128
14. Databases and Collections in MongoDB, https://www.mongodb.com/docs/manual/core/databases-and-collections/
15. JSON And BSON - MongoDB, https://www.mongodb.com/resources/basics/json-and-bson
16. JSON vs BSON vs JSONB - A Detailed Comparison - OLake, https://olake.io/blog/json-vs-bson-vs-jsonb
17. JSON vs. BSON Format: Differences, Advantages, & More - Couchbase, https://www.couchbase.com/resources/concepts/json-vs-bson/
18. Difference Between JSON and BSON - GeeksforGeeks, https://www.geeksforgeeks.org/javascript/difference-between-json-and-bson/
19. mongodb - What is BSON and exactly how is it different from JSON? - Stack Overflow, https://stackoverflow.com/questions/12438280/what-is-bson-and-exactly-how-is-it-different-from-json
20. What Is a Document Database? - Document DBs and Stores Explained - AWS, https://aws.amazon.com/nosql/document/
21. Advantages & Disadvantages of Using MongoDB (2025) - RalanTech, https://www.ralantech.com/resources/advantages-disadvantages-of-using-mongodb-2025/
22. Convert a Standalone Self-Managed mongod to a Replica Set - Database Manual, https://www.mongodb.com/docs/manual/tutorial/convert-standalone-to-replica-set/
23. Replica Sets and Shards in MongoDB: Architecture and Benefits | by Aditya Yadav | Medium, https://dev-aditya.medium.com/replica-sets-and-shards-in-mongodb-architecture-and-benefits-a3c83f39e4f0
24. Replica Set Deployment in MongoDB - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/replica-set-deployment-in-mongodb/
25. MongoDB Replication: A Complete Introduction – BMC Software | Blogs, https://www.bmc.com/blogs/mongodb-replication/
26. Replica Set Members - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/core/replica-set-members/
27. Mastering MongoDB Replica Sets: An In-Depth Exploration — Part 1 | by Ajay Rajput, https://medium.com/@rajputajy2811/mastering-mongodb-replica-sets-an-in-depth-exploration-part-1-799305ffa0f2
28. Sharding - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/sharding/
29. MongoDB Sharding, https://www.mongodb.com/resources/products/capabilities/sharding
30. Database Sharding: Concepts & Examples - MongoDB, https://www.mongodb.com/resources/products/capabilities/database-sharding-explained
31. Demystifying Sharding with MongoDB, https://www.mongodb.com/blog/post/demystifying-sharding-mongodb
32. Sharded Cluster Components - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/core/sharded-cluster-components/
33. Understanding MongoDB’s Sharding Architecture: A Step-by-Step Guide with Real-World Use Cases - enginEBogie, https://enginebogie.com/public/charchaa/post/understanding-mongodb-s-sharding-architecture-a-step-by-step-guide-with-real-world-use-cases/94
34. MongoDB CRUD Operations, https://www.mongodb.com/resources/products/fundamentals/crud
35. How to Execute Create, Read, Update and Delete Operations in MongoDB, https://delbridge.solutions/mongodb-crud-operations/
36. CRUD Operations in MongoDB - Analytics Vidhya, https://www.analyticsvidhya.com/blog/2022/12/crud-operations-in-mongodb/
37. Indexes - Database Manual v6.0 - MongoDB Docs, https://www.mongodb.com/docs/v6.0/indexes/
38. Aggregation Operations - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/aggregation/
39. MongoDB Aggregation Pipeline, https://www.mongodb.com/resources/products/capabilities/aggregation-pipeline
40. Aggregation in MongoDB: $match, $group, $sort - TutorialsTeacher, https://www.tutorialsteacher.com/mongodb/aggregation
41. Learn MongoDB Aggregation with real world example — Cloudnweb | by ganesh mani, https://ganeshmani009.medium.com/learn-mongodb-aggregation-with-real-world-example-cloudnweb-3ddec4e091cc?source=follow_footer———0––––––––––––––
42. $match (aggregation) - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/reference/operator/aggregation/match/
43. Aggregation in MongoDB - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/aggregation-in-mongodb/
44. $project (aggregation) - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/reference/operator/aggregation/project/
45. $sort (aggregation) - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/reference/operator/aggregation/sort/
46. $sort (aggregation) — MongoDB Manual 3.4, https://mongoing.com/docs/reference/operator/aggregation/sort.html
47. MongoDB Aggregation Pipeline $limit - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/aggregation-pipeline-limits/
48. Aggregation Pipeline Stages - Node.js Driver - MongoDB Docs, https://www.mongodb.com/docs/drivers/node/current/aggregation/pipeline-stages/
49. Complete Aggregation Pipeline Tutorials - Database Manual - MongoDB Docs, https://www.mongodb.com/docs/manual/tutorial/aggregation-complete-examples/
50. Analytics Driven By MongoDB | MongoDB, https://www.mongodb.com/solutions/use-cases/analytics
51. Atlas Database | MongoDB, https://www.mongodb.com/products/platform/atlas-database
52. Get Started with Atlas - Atlas - MongoDB Docs, https://www.mongodb.com/docs/atlas/getting-started/
53. MongoDB Compass, https://www.mongodb.com/products/tools/compass
54. What is MongoDB Compass?, https://www.mongodb.com/docs/compass/
55. MongoDB Developer Tools, https://www.mongodb.com/products/tools
56. MongoDB Advantages & Disadvantages - GeeksforGeeks, https://www.geeksforgeeks.org/mongodb/mongodb-advantages-disadvantages/
57. The Big Data Guide | MongoDB, https://www.mongodb.com/resources/basics/big-data-explained
58. Best 7 Real-World MongoDB Use Cases - Hevo Data, https://hevodata.com/learn/mongodb-use-case/
59. MongoDB vs MySQL - Difference Between Database Management Systems - AWS, https://aws.amazon.com/compare/the-difference-between-mongodb-vs-mysql/
60. MongoDB vs. MySQL: Compare Database Performance & Speed - Integrate.io, https://www.integrate.io/blog/mongodb-vs-mysql/